為什麼不直接開始寫 Code?

拿到資料的直覺往往是直接用 read_csv 讀取，但這在業界可以說是大忌!
資料不是平的： 企業數據通常分散在多張關聯式資料表（RDB）中。
ER Diagram 就是「建築設計圖」： 不看設計圖就合併資料，絕對會把訂單張冠李戴。
今天，先用 3 個模組看懂 Olist 巴西電商的「數據設計圖」。
如下圖1

圖1

1. 交易與金流模組-公司的「記帳本」

這是整間公司的命脈，紀錄「誰、何時、買了什麼、花多少錢」。

• 訂單主表 (orders)： 紀錄訂單狀態與時間戳記。
  （就像你在網購時，系統紀錄包裹是剛離開台北的物流中心，還是已經送達新北的超商）。
• 訂單明細表 (order_items)： 紀錄買了哪項商品、單價與運費。
• 支付表 (order_payments)： 紀錄結帳方式（信用卡、實體帳單等）。

2. 商品與評論模組-公司的「型錄」與「客訴信箱」

用來分析「商品熱門度」與「顧客滿意度」。

• 商品表 (products)： 紀錄長寬高、重量與商品類別。
• 品類翻譯表 (category_translation)：負責把巴西葡文翻譯成英文。
  （畢竟我們看葡萄牙文，就像外國人看我們商品裡寫新北特產一樣霧煞煞）。
• 評論表 (order_reviews)： 紀錄 1~5 星評分與文字留言。

3. 用戶與地理模組-公司的「戶口名簿」與「地圖」

• 客戶/賣家表 (customers / sellers)： 紀錄買賣雙方的唯一識別碼與所在州別。
• 地理資訊表 (geolocation)： 紀錄巴西郵遞區號對應的精確實體經緯度。
  （概念就像把系統裡的代碼，精確定位成「新北市板橋區」地圖上的一個座標點）。

邏輯推演：跨表連連看

看懂表單後，我們來嘗試推演真實的商業情境。
假設營運長問：「聖保羅州（SP）的顧客，最常給差評的商品是什麼？」
這好比在詢問：「住在新北市的買家，最常對哪一種商品留下負評？」
找答案的過程，必須透過主鍵（PK）與外鍵（FK）一路追蹤：

• ＂抓＂　出人： 從「客戶表」篩選出聖保羅州的買家。
  　（就像先在系統裡框出所有新北市的用戶）。
• ＂找＂　出單： 連線到「訂單主表」，找出這些買家的訂單編號。
• ＂篩＂　出怨： 連線到「評論表」，鎖定 1 星或 2 星的差評訂單。
• ＂抓＂　兇手： 最後連線到「訂單明細」與「商品表」，精準揪出地雷商品。

資料集 來自於 :
[Brazilian E-Commerce Public Dataset by Olist]
(https://www.kaggle.com/datasets/olistbr/brazilian-ecommerce)

今天我們了解這 9 張表的底層邏輯，確認了 - 主鍵&外鍵 的對應關係。
這張地圖將是我們接下來實作 ETL 時，避免在複雜關聯中迷失方向的關鍵指南。
明天，我們將正式開啟 VS Code 開發環境，用最有效率的方式把這些資料喚醒。
我們 Day 3 見！